home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / tnfs / tnfs-minutes-92may.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.2 KB  |  188 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Fred Glover/DEC
  5.  
  6. Minutes of the Trusted Network File Systems Working Group (TNFS)
  7.  
  8. May 1992
  9.  
  10. Agenda
  11.  
  12.  
  13.    o Reviewed the recent modifications to the TNFS document (TNFS-001.2.02)
  14.    o Reviewed the TKM document (TNFS-006.01.01)
  15.    o Reviewed implementation status and issues
  16.    o Discussed Lock Manager impact
  17.    o Discussed TNFS auditable events
  18.  
  19.  
  20. TNFS Document Review
  21.  
  22. The IETF TNFS document has been available for comments in the IETF Draft
  23. Directory and TNFS archive since July, 1991.  During the May meeting,
  24. the Working Group made ``final'' wordsmithing modifications, and edits
  25. to the document.  This concludes the work planned for the TNFS
  26. specification, and the next steps are to transition the document to
  27. Proposed Standard.  Trusted Systems technology providers are encouraged
  28. to commence implementation based upon the current TNFS draft.
  29.  
  30. Final updates to the TNFS document include:
  31.  
  32.  
  33.    o Add vendor specific token to directory response structure, set
  34.      label procedure arguments.
  35.    o Change the arguments to the MLD procedure to reference operations
  36.      rather than flags.
  37.    o Add explicit indication within ACCESS and file open sections to
  38.      identify conditions in which a client caching security attributes
  39.      must revalidate the rights of a given client application (i.e., by
  40.      calling ACCESS).
  41.    o Add rationale indicating why security attribute tokens are not
  42.      required to be included in the read directory response structure.
  43.  
  44.  
  45. We spent some additional time discussing auditing.  Conclusions include:
  46.  
  47.  
  48.    o Some environments may require that both client and server auditing
  49.      is enabled in order to ensure full audit of events such as:
  50.  
  51.       -  First read (server audits; may need to check audit id and XID
  52.  
  53.                                    1
  54.  
  55.  
  56.  
  57.  
  58.  
  59.          in order to identify actual issuing PID if that is required).
  60.       -  Floating of objects (server only; client can't see).
  61.       -  Server override of privileges (server only; client can't see).
  62.  
  63.    o The transaction ID is a possible ``key'' which can be used to
  64.      correlate a client request with the server side procedure.
  65.  
  66.  
  67. An updated document will be placed in the IETF and TNFS archives after
  68. an ``email'' review of the updates has been completed.  In addition,
  69. Fred will contact our IETF Area Director, Dave Borman, to understand our
  70. ``next steps'' in the standardization process.
  71.  
  72. Token Manager Review
  73.  
  74. The TKM document was also reviewed.  It now contains an attribute to
  75. token procedure.  The following updates will be made to the document:
  76.  
  77.  
  78.    o Editorial (wordsmithing).
  79.    o Length field added to string arguments.
  80.  
  81.  
  82. The updated TKM document will be placed into the IETF Draft Directory
  83. (informational RFC) and the TSIG TNFS archive.
  84.  
  85. We have been reviewing both the TKM and MAC6 token mapping proposals.
  86. Our current recommendation is for each of these to be submitted as IETF
  87. informational RFCs.  One of these would be identified to become the
  88. actual standard, once all of the IETF/TSIG token mapping requirements
  89. were understood and were accommodated by at least one of these
  90. proposals.  We recommended that a new working group be formed which
  91. would assume the responsibility of collecting the requirements,
  92. reviewing all of the proposals, and making recommendations.
  93.  
  94. Implementation Status, Issues
  95.  
  96. The Working Group reviewed the progress of current implementation
  97. efforts.  Two implementations are very ``close'' to conformance with the
  98. current version of the specification.  We discussed testing
  99. possibilities for the end of this year.  We have already identified a
  100. test plan, a set of ``non-mapped'' security attributes for testing, and
  101. a modified test routine to be used with the Connectathon test suite.  An
  102. update of the tnfs.h file, describing all of the TNFS procedures and
  103. data structures, will be placed into the TSIG/IETF archive to facilitate
  104. development of additional implementations.
  105.  
  106. Lock Manager Update
  107.  
  108. Charlie Watt recently completed a review of the NFS lock manager and
  109. suggests that no changes appear to be required to the lock manager to
  110.  
  111.                                    2
  112.  
  113.  
  114.  
  115.  
  116.  
  117. work in the TNFS environment.  This confirmed the results of an earlier
  118. Working Group discussion and closes an action item.  Thanks Charlie!
  119.  
  120. TNFS Auditable Events
  121.  
  122. We started the discussion of TNFS auditable events at this meeting.
  123. Mark Saake will be developing a document which describes this area.
  124. Conclusions reached at this meeting:
  125.  
  126.  
  127.    o The TNFS Group will focus on server side (i.e., protocol procedure)
  128.      auditable events; we will expect that POSIX will identify the
  129.      client side (i.e., application, API based) events and formats.
  130.    o When the server receives a TNFS request, it can identify:
  131.  
  132.       -  Host address (and thus host)
  133.       -  File handle
  134.       -  Export structure
  135.       -  Procedure number
  136.       -  Version number
  137.       -  Credential information (ID info); result of subsequent
  138.          authorization check (i.e., pass or fail).
  139.       -  Log entry and exit status of each called TNFS server procedure.
  140.  
  141.  
  142. Next Meeting
  143.  
  144. The TNFS Group will plan to meet jointly with IETF and TSIG at the July
  145. meeting in Boston.  At that meeting, we plan to:
  146.  
  147.  
  148.    o Present a summary to interested IETF attendees during a designated
  149.      two hour time slot.
  150.    o Review the ``final'' version of the TNFS documents (updated
  151.      documents placed into the TNFS archive and IETF Drafts Directory:
  152.      Fred, Fran, Carl, Ali).
  153.    o Review the interoperability test opportunities, plans (all).
  154.    o Review NFS test suite extension for TNFS (Fran).
  155.    o Identify conforming implementations to support our request to
  156.      transition our TNFS document (all).
  157.    o Review identification of auditable TNFS events (Mark).
  158.    o Place ``tnfs.h'', test plan, test attributes into TNFS archive
  159.      (Fred).
  160.  
  161.  
  162.  
  163.                                    3
  164.  
  165.  
  166.  
  167.  
  168.  
  169. The July meeting is planned for the 13th-17th at the Hyatt Regency in
  170. Cambridge, Massachusettes.
  171.  
  172. Attendees
  173.  
  174. Lida Carrier             lida@apple.com
  175. Fran Fadden              fran@decvax.dec.com
  176. Jonathon Fraser
  177. Fred Glover              fglover@zk3.dec.com
  178. Ali Gohshan
  179. Brian Hardy
  180. Mark Saake               saake@netcom.netcom.com
  181. Carl Smith               cs@eng.sun.com
  182. T.T. Tao
  183. Charles Watt             watt@sware.com
  184.  
  185.  
  186.  
  187.                                    4
  188.